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SYSTEM, APPARATUS AND METHOD OF ENHANCING PRIORITY BOOSTING 

OF SCHEDULED THREADS 

5 BACKGROUND OF THE INVENTION 

1. Technical Field: 

The present invention is directed to resource 
allocations in a computer system. More specifically, the 
10 present invention is directed to a system, apparatus and 
method of enhancing priority boosting of a scheduled thread. 

2. Description of Related Art: 

At any given processing time, there may be a 

15 multiplicity of processes or threads waiting to be executed 
on a processor or CPU of a computing system. To best 
utilize the CPU of the system then, it is necessary that an 
efficient mechanism that properly queues the processes or 
threads for execution be used. The mechanism used by most 

2 0 computer systems to accomplish this task is a scheduler. 

Note that a process is a program. When a program is 
executing, it is loosely referred to as a task. In most 
operating systems, there is a one-to-one relationship 
between a task and a program. However, some operating 

25 systems allow a program to be divided into multiple tasks or 
threads. Such systems are called multithreaded operating 
systems. For the purpose of simplicity, threads and 
processes will henceforth be used interchangeably. 

A scheduler is a software program that coordinates the 

30 use of a computer system's shared resources (e.g., a CPU). 
The scheduler usually uses an algorithm such as a first-in, 
first-out (i.e., FIFO), round robin or last-in, first-out 
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(LIFO) , a priority queue, a tree etc. algorithm or a 
combination thereof in doing so. Basically, if a computer 
system has three CPUs (CPUi, CPU 2 and CPU 3) , each CPU will 
accordingly have a ready-to-be-processed queue or run queue. 
5 If the algorithm in use to assign processes to the run queue 
is the round robin algorithm and if the last process created 
was assigned to the queue associated with CPU 2/ then the 
next process created will be assigned to the queue of CPU 3 . 
The next created process will then be assigned to the queue 

10 associated with CPUi and so on. Thus, schedulers are 
designed to give each process a fair share of a computer 
system' s resources . 

Sometimes a system administrator may want different 
processes to receive a different share of the CPU time, for 

15 example. In that case, a workload manager (WLM) is used in 
conjunction with the scheduler. The WLM assigns a priority 
number to each process. Each time a process consumes some 
CPU time, its priority number is reduced. This scheme 
allows processes that have a lower priority number to 

2 0 nonetheless receive some CPU time. 

When a process is being processed by a CPU and for some 
reason needs to wait for an event to occur before 
proceeding, for efficiency reasons, the process may cede the 
rest of its turn at the CPU to another process and goes to 

2 5 sleep. If the process has a lock on a shared kernel 

resource, it will not relinquish the lock before it goes to 
sleep. For example, when a first process is using a shared 
kernel resource such as a buffer, it will put a lock on the 
buffer to prevent all other processes from using the buffer. 

3 0 If the first process was performing some disk input /output 

(I/O), it may allow another process to use the CPU and go to 
sleep while the disk I/O is completing. Once the disk I/O 
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has completed, the first process may awaken. If a second 
process with a higher priority number needs to use the 
buffer in the mean time, it will have to wait until the 
first process obtains some CPU time to complete its task and 
5 release the lock on the buffer. 

To reduce the amount of time the second process may 
have to wait, priority boosting has been used. Priority 
boosting occurs when a second process with a higher priority 
number passes its priority number to a first process with a 

10 lower priority number and which has a lock on a needed 
shared resource to increase the first process' likelihood at 
being the next process chosen to receive some CPU time. As 
will be explained later, although it now has a higher 
priority number, the first process may not obtain the CPU 

15 right away if another process is currently using the CPU. 

Thus, what is needed is a system and method of 
enhancing priority boosting such that a process that has a 
lock on a shared resource and whose priority has been 
boosted may obtain some CPU time as soon as possible. 



20 
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SUMMARY OF THE INVENTION 

The present invention provides a system, apparatus and 
method of enhancing priority boosting of scheduled threads. 
5 If, while being executed by a second CPU, a second thread 
determines that it has to wait for a lock on a shared 
resource held by a first thread that is scheduled to be 
executed by a first CPU, the second thread may boost the 
priority of the first thread by passing its priority to the 

10 first thread if its priority is higher than the first 
thread's priority. Further, to enhance the priority boost 
of the first thread, the second thread may reschedule the 
first thread to be processed by the second CPU. By having 
been rescheduled on the second CPU, the second thread may be 

15 dispatched for execution right thereafter. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 
5 invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best be 
understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 
10 Fig. la depicts run queues of a multiprocessor computer 

system. 

Fig. lb depicts the run queues of the multiprocessor 
system after Thi has been dispatched. 

Fig. lc depicts the run queues of the multiprocessor 
15 after Th 4 has been dispatched. 

Fig. Id depicts the run queues of the multiprocessor 
after Th 2 has been dispatched. 

Fig. le depicts the run queues of the multiprocessor 
after an awakened Thi has been pulled into the run queue of 
2 0 CPUi. 

Fig. If depicts the run queues of the multiprocessor 
after Thi has released a lock needed by Th 2 (i.e., Th 2 has 
awakened) and provided that the priority of Th 2 remains 
higher than that of Th 5 . 
2 5 Fig. 2 is a flowchart of a process that may be used to 

implement the invention. 

Fig. 3 is a block diagram of a data processing system 
on which the invention may be implemented. 



- 6 - 

Docket No. AUS920030439US1 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

With reference now to the figures, Fig. la depicts run 
queues of a multiprocessor computer system. The computer 
5 system contains three processors, CPU 0 110, CPUi 112 and CPU 2 
114. CPU 0 110 has a run queue 102. Threads Thi, Th 4/ Th 7 
etc. are scheduled to run on CPU 0 110 and thus are in run 
queue 102. Likewise, CPU X 112 has a run queue 103 in which 
threads Th 2 , Th 5 , etc., which are scheduled to run on CPUi 

10 112, are placed and CPU 2 114 has a run queue 104 in which 
threads Th 3 , Th 6 , etc., which are scheduled to run on CPU 2 
114 are placed. The threads will be dispatched for 
execution in their order in the run queues unless a new 
thread with a higher priority is placed in the run queues. 

15 When CPU 0 110 is ready to process Thi, Thi will be 

dispatched for execution. Now, suppose Thi's task is to 
load data into a buffer (not shown) , then Thi will have a 
lock on the buffer to prevent other threads from using the 
buffer. Since disk I/O is a relatively slow process, while 

2 0 the disk I/O is being performed, Thi may go to sleep and 
relinquish CPU 0 110. Since Thi is not presently using CPU 0 
110, Th 4 may now be dispatched to be processed by CPU 0 110. 
Suppose further that Th 2 is dispatched on CPUi 112 and needs 
to use the buffer, Th 2 will not be processed since it has to 

2 5 wait for Thi to release the lock on the buffer. For Thi to 
release the lock, it has to first obtain some processing 
time. To complete its task and release the lock on the 
buffer, Thi may receive processing time from any available 
processor in the computer system. However, for the purpose 

30 of explaining the invention, it will be assumed that Thi 
needs to receive some processing time on CPU 0 110. Hence, 
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Thi may have to wait until Th 4 has had its processing turn 
on CPU 0 110 before it can continue. 

As mentioned before, to increase the likelihood that 
Th x may be the next thread chosen to run on CPU 0 110 after 
5 Th 4 has gotten its share of CPU 0 time, priority boosting may 
be used. In that case, when Th 2 realizes that it has to 
wait for the lock to be released by Thi, it will pass its 
priority number to Th x . The problem, however, is that 
unless CPU 0 110 is executing kernel code that can notice the 

10 priority boost, CPU 0 110 may not notice the priority boost 
up to 10 milliseconds (ms) thereafter when a time slice 
interrupt occurs. In most Unix-based systems, time slice 
interrupts occur periodically (e.g., every 10 ms) and are 
used by the kernel to check to see whether a thread with a 

15 higher priority is ready to run while the CPU is processing 
a thread with a lower priority. 

To continue with the example above, after thread Thi 
has received the priority boost, it may still have to wait 
up to 10 ms before it may be processed once more by CPU 0 

2 0 110. 10 ms in computer time is a long time. The present 
invention provides an algorithm that may be used to enhance 
priority boosting of a scheduled thread. 

According to the invention, after passing its priority 
to Thi, Th 2 may also hand off its CPU time to Thi by pulling 

2 5 Thi into CPUi's run queue before it goes to sleep. Based on 

this priority, Thi may be dispatched for execution right 
after it has been pulled into CPUi's run queue if it has 
already been awakened (i.e., the disk I/O has completed). 
Thus Th 5 , the next thread scheduled to run on CPUi, will now 

3 0 have to wait before being dispatched for execution. 

Fig. lb depicts the run queues of the multiprocessor 
system after Thi has been dispatched. Fig. 1c depicts the 
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run queues of the multiprocessor after Th 4 has been 
dispatched. Fig. Id depicts the run queues of the 
multiprocessor after Th 2 has been dispatched. Fig. le 
depicts the run queues of the multiprocessor after an 
5 awakened Thi has been pulled into the run queue of CPUi 112. 
Fig. If depicts the run queues of the multiprocessor after 
Thi has released the lock (i.e., Th 2 has awakened) and 
provided that the priority of Th 2 remains higher than that 
of Th 5 . 

10 Fig. 2 is a flowchart of a process that may be used to 

implement the invention. The process starts when a thread 
(i.e., a second thread) has been dispatched to a second CPU 
for execution (steps 200 and 202). If while being executed, 
the second thread realizes that it needs to place a lock on 

15 a shared resource which is being held by a first thread, the 
second thread may check to see whether the first thread has 
a lower priority than its own. If so, the second thread may 
boost the priority of the first thread by passing to the 
first thread its own priority. That way the first thread 

2 0 may be dispatched faster for execution. After passing its 

own priority to the first thread, the second thread may 
again check to see whether the first thread is scheduled to 
run on a first CPU or the second CPU. If the first thread 
is scheduled to run on the first CPU, the first thread may 
25 be rescheduled to be executed on the second CPU before the 
process ends (steps 204, 208, 210, 212, 214 and 216). 

If the second thread does not need to place a lock on a 
shared resource or if the second thread does not have a 
higher priority that the first thread or if the first thread 

3 0 is scheduled to be processed by the second CPU, the process 

may continue as customary before it ends (steps 2 04, 2 06 and 
216 or 208, 206 and 216 or 212, 206 and 216, respectively) . 
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Fig. 3 is a block diagram of a data processing system 
on which the invention may be implemented. Data processing 
system 3 00 may be a symmetric multiprocessor (SMP) system 
including a plurality of processors 302, 303 and 304 
5 connected to system bus 306. Also connected to system bus 
306 is memory controller/cache 308, which provides an 
interface to local memory 309. I/O bus bridge 310 is 
connected to system bus 3 06 and provides an interface to I/O 
bus 312. Memory controller/cache 308 and I/O bus bridge 310 

10 may be integrated as depicted. 

Peripheral component interconnect (PCI) bus bridge 314 
connected to I/O bus 312 provides an interface to PCI local 
bus 216. A number of modems may be connected to PCI local 
bus 316. Typical PCI bus implementations will support four 

15 PCI expansion slots or add- in connectors. Network 
communications may be provided through modem 318 and network 
adapter 320 connected to PCI local bus 316 through add-in 
boards. Additional PCI bus bridges 322 and 324 provide 
interfaces for additional PCI local buses 326 and 328, from 

2 0 which additional modems or network adapters may be 
supported. In this manner, data processing system 300 
allows connections to multiple network computers. A memory- 
mapped graphics adapter 330 and hard disk 332 may also be 
connected to I/O bus 312 as depicted, either directly or 

2 5 indirectly. 

Those of ordinary skill in the art will appreciate that 
the hardware depicted in Fig. 3 may vary. For example, 
other peripheral devices, such as optical disk drives and 
the like, also may be used in addition to or in place of the 

3 0 hardware depicted. The depicted example is not meant to 

imply architectural limitations with respect to the present 
invention. 



- 10 - 

Docket No. AUS920030439US1 

The data processing system depicted in Fig. 3 may be, 
for example, an IBM e-Server pSeries system, a product of 
International Business Machines Corporation in Armonk, New 
York, running the Advanced Interactive Executive (AIX) 
5 operating system or LINUX operating system. 

The description of the present invention has been 
presented for purposes of illustration and description, and 
is not intended to be exhaustive or limited to the invention 
in the form disclosed. Many modifications and variations 

10 will be apparent to those of ordinary skill in the art. For 
example, threads of fixed priorities may be used rather than 
of variable priorities. Thus, the embodiment was chosen and 
described in order to best explain the principles of the 
invention, the practical application, and to enable others 

15 of ordinary skill in the art to understand the invention for 
various embodiments with various modifications as are suited 
to the particular use contemplated. 



